The operating system (OS) kernel is the software forming the core or heart of an OS. The kernel is loaded into main memory first on startup of a computer and remains in main memory providing essential services, such as memory management, process and task management and disk management. The kernel manages nearly all aspects of process execution on a computer system. Processes may be typical programs such as word processors, spreadsheets, games or web browsers. Processes are also underlying tasks executing to provide additional functionality to either the operating system or to the user of the computer. Processes may also be additional processes of the operating system for providing functionality to other parts of the operating system, e.g., networking and file sharing functionality.
The kernel is responsible for scheduling the execution of processes and managing the resources made available to and used by processes. The kernel also handles such issues as startup and initialization of the computer system.
As described above, the kernel is a very important and central part of an OS. Additional software or code, be it a program, process, or task, is written for execution on top of or in conjunction with the kernel, that is, to make use of kernel-provided services, information and resources.
Configurable kernel parameters (known as “tunables”) are usually managed manually.
Such things as the system hostname, the current time of day, and the identification of the boot device could all be considered kernel parameters in the broadest sense of the term. Seen that broadly, there are many different variables, parameters and settings that affect kernel behavior and also many different mechanisms by which the kernel is managed.
The term “tunables” however refers to the set of parameters that historically are compiled into the kernel image. This mechanism dates back to the earliest types of UNIX in the mid-70s. So do many of the tunables themselves, such as nproc, maxdsiz and semmns. Historically, the set of tunables was defined by a file called master and the per-system customized values of those tunables were stored in a file called either system or dfile. A program called config would read those files and use them to generate a file of C code (conf.c), which was then compiled and linked with the kernel code. This process is known as “rebuilding the kernel.” The resulting customized kernel could then be booted and used.
Over the years prior to this invention, this process of configuring tunables has changed only superficially. The master file has been replaced with a directory full of files. The SAM program and mk_kernel command present simpler interfaces to this process. The kmtune command, part of the Dynamically Loadable Kernel Modules (DLKM) infrastructure, allows for multiple kernel modules to be configured using this process, each with their own master files, system files and resulting binary image. But throughout all of these enhancements prior to this invention, the bottom line has been the same: the kernel must be rebuilt and rebooted in order for the tunable value changes to take effect. With this invention in place, we define a static tunable as one whose value cannot be changed without rebooting the system. Usually a kernel rebuild is also required. But with this invention, a tunable may be either static or dynamic. A dynamic tunable is one that can be changed without rebooting the system.
Many UNIX users are greatly concerned with high availability. Businesses can incur significant losses when a critical system goes down for an hour. In many customer environments, it is often difficult to justify rebooting a system in order to tune it.
One difficulty with prior art approaches to dynamic tunables is that there is one mechanism used to change the value of a tunable while the system is running. An entirely separate and different mechanism is used to change the value of the tunable in a permanent fashion to last across reboots. Disadvantageously, the tunable needs to be changed twice.